Organizations employ a variety of processes to achieve organizational and/or business goals. Oftentimes, these processes can involve both manual and automated activities. In other words, the processes require both human action and machine-based (e.g., software or computer driven) action. To better achieve overall business and/or organizational goals, organizations are increasingly relying on workflow management to streamline their processes and activities. Workflow management typically focuses on how a product (i.e., a “workflow”) flows through a particular process. In the context of a manufacturing line, for example, workflow management can be used to streamline how “work in process” matriculates through the manufacturing line. As another example, in the context of web design, workflow management can focus on how content is manipulated for deployment on the worldwide web.
To implement workflow management techniques, many organizations utilize software packages or “workflow engines” provided by software vendors. Depending on the functionality provided by a particular workflow engine, the organization can initiate actions based on the occurrence of certain events defined by the organization. Based on the process definition (i.e., a computer prosecutable representation of a real-world process), the workflow engine can initiate various actions to aid an actual implementation of a process. For example, if a content provider defined a process to include the activities of authoring and editing content, the workflow engine can be configured to notify an editor (e.g., via email, paging or other media) when the author has finished working on a particular content item. In this manner, the editor will know almost immediately when he or she can edit the content item.
As workflow management has evolved, software vendors have deployed a wide range of workflow engines. Each software vendor typically developed a specific workflow engine based on the needs of a customer. Thus, while many workflow engines are available, each engine often possesses particular functional capabilities, strengths and weaknesses. In order to utilize a particular workflow engine, an organization must generally develop applications that interface with the workflow engine through the workflow engine's application program interface (API). As would be understood by those of ordinary skill in the art, an API is a set of routines, protocols and/or tools that can be used to develop applications that function with a particular workflow engine. Unfortunately, prior art workflow engines utilize proprietary APIs. This can present significant shortcomings for the deployment of workflow management tools across an enterprise or among cooperating, but disparate, enterprises.
As noted earlier, each workflow engine tends to have particular strengths and weaknesses, and a workflow engine that was previously adequate for an organization may now be unsatisfactory because the organization has changed size, processes, or so on. Because each workflow engine typically uses a vendor-specific API, the organization may be required to develop an entirely new set of workflow applications in order to utilize a new workflow engine. Thus, the organization is either left with an inadequate workflow management solution or must incur the additional expense of developing new applications. As an additional shortcoming, process definitions that were valid for one workflow engine may be invalid for another workflow engine. When an organization implements a new tier (i.e., deploys a new workflow engine), it may have to redevelop its entire process definitions.
To illustrate disparate means for implementing workflow engines and the shortcomings thereof, consider the following examples. IBM® has deployed a workflow engine using functional definition language (FDL). FDL is a text-based language that is essentially compiled, but it is not a programming language such as Java or C++. In order to use the IBM® workflow engine, an organization must develop applications that are compatible with FDL. On the other hand, BEA® Systems uses an XML-based language for process definition representation. Therefore, an organization's applications would have to be compatible with BEA's® process definition representation in order to utilize the BEA® Systems workflow engine. Additionally, both the IBM® workflow engine and the BEA® Systems workflow engine have completely different APIs. Thus, in order to implement both the BEA® Systems workflow engine and the IBM® workflow engine in the same workflow management system, the organization may have to develop two entirely different sets of process definitions and two entirely different sets of applications in order to interface with the respective APIs.
FIG. 1 further illustrates the shortcomings of prior art workflow management systems. Prior art workflow management systems can include multiple workflow engines (e.g., workflow engine 102 and workflow engine 104). Each workflow engine can include a proprietary API. For example, workflow engine 102 can include API 112 and workflow engine 104 can include API 114. For an application to run with each workflow engine, the application must be tailored to the proprietary APIs. Thus, in the embodiment of FIG. 1, a particular application 120 can be divided between sub-application 122 and sub-application 124. These applications can have the same functionality, but require customized programming to interface with API 112 and 114 respectively. If the organization implementing the workflow management system of FIG. 1 wants to interface application 120 with additional workflow engines, the organization must typically develop new sub-applications of application 120 to interface with the proprietary APIs of the new workflow engines. Because each workflow engine can employ a proprietary API, the organization can incur significant programming expenses adapting application 120 to each new workflow engine.
Several standards have been developed for the representation and implementation of workflow products interface. However, vendor-specific workflow engines have either not adopted these standards or have only partially adopted them. Thus, organizations are left to implement heterogeneous workflow management products, each of which may be individually unsatisfactory for a particular organization's processes.